Description

This change introduces the collection of metrics for GoCert. These metrics are the ones described in the GoCert backend specification, and two metrics specific to the webserver: Total number of requests and Request Latency.

There are 2 main methods of collecting these metrics:

• As middleware that can sit between the endpoint handlers and the request and responses, and record anything that happens.
• As a separate goroutine that periodically queries the DB to update the metrics.

There are pros and cons to doing either.

Middleware

For the middleware method, the main pro is that there is visibility to every process the webserver does, whether that's auth, logs, or anything in the request and response objects. This is nice for collecting information about the webserver, like number of failed logins, IP addresses of the requests, internal server errors etc.

It is not a good idea to collect metrics about things where the source of truth is not the requests themselves. This couples the API to the metrics themselves (how do we know the deleted CSR was outstanding or not without passing this info specifically?), introduces complex code to correctly identify the resource being edited and may lead to desync issues with the data in the database and the metrics (if we fail to pass the outstanding or not information to the middleware).

GoRoutine

For the goroutine method, the benefit is the fact that the metrics are collected from the source of truth, which means the metrics are always eventually consistent. It's also completely decoupled from the metrics endpoint, which means we get to make decisions about moving the handler to different ports or servers without messing with the metrics collection logic and vice versa.

The downside is, the cadence of the collection means there will need to be a balance between how up-to-date the metrics are at any given time and the amount of load and processing power we need to use from the host and the DB to collect these metrics. Considering the fact that certificates are low in number and the metrics for them change very infrequently, this is not a problem even if we choose to collect metrics every 6 hours.

This PR initializes the cadance value at 120 seconds. This can be set as a config option in the future.

In this PR there's examples of doing both, which should be chosen considering these factors when defining future metrics.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that validate the behaviour of the software
• I validated that new and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules